Part 40: Assignment #17: Aquaponics Maintenance Robot
Aquaponics Maintenance Robot
I'm feeling a little relieved. This is a serious project, it's not defense-org-y at all, and the only fishy thing about it is that it's part of a system that is full of literal fish.
I'd give Lili a high-five if she was the kind of person to be into high-fives.
Looking at the design, this definitely feels like a two-MC project. There's three outputs - and two of them (the feeding and cleaning tools) do only need to be pulsed, so the design could use an output expander - but if I were to use an expander, it'd take five instructions to pulse the outputs versus two without one.*
There's also the matter that there's no way to get the current position of the arm. Whatever I build will have to keep track of that itself - over multiple time units, given that the arm can only move one space at a time.
*( {mov 100 x#, slp t1, mov 10 x#, slp t2, mov 0 x#} versus {gen p0 t1 0, gen p1 t2 0}. )
With that in mind, I think a preliminary design would look something like this:
The code for the first MC is pretty much written. It waits for data from the receiver, then passes the destination on to the second MC (which will control the motor). Then, once the second MC signals the arm is in place, the first MC uses gen to pulse the cleaning / feeding tools. (This relies on the trick I learned about after the virtual reality buzzer job - that the radio will hold the back end of the data packet until the first MC asks for it.)
Now I just have to write the code for the second MC.
[ ~ ]
Remember how I said the design would have to keep track of the position of the arm over multiple time units? It turns out, to make the motor routine work, it has to keep track of both the current position of the arm... and the destination. Which requires two registers to keep track of.
As such, the second MC is now a MC6000. acc stores the current position, dat stores the target position - the MC waits for a destination, then pulses the motor and updates acc to match the new position.
(In case you're wondering about the gen instructions, they set the motor to 100 or 0, respectively - the 'mov 50' resets it back to a neutral state afterwards.)
So this design is a wrap. ¥8, 196 average power. Pretty efficient, in my opinion.
That said - I think there at least could be a way to do this with two MC4000s. A lot of instructions on the big MC are repeated, so it feels like the number could be lowered - but how to cope with the loss of the extra register?
I'll have to fiddle with it a bit.
[ ~ ~ ]
Success! Suc-freaking-cess!
Getting the job done with ¥6 (and 277 average power) required redesigning a lot of things. First off, there's the question of where to store the arm's destination. The first MC uses its acc to store the destination now - it repeatedly sends it to the second MC every other time unit until the second MC reports that it's at the location. (The jmp to 'redo' is the loop.)
The second MC has been simplified. It just reports its current location, then updates its acc (the current arm position) and pulses the motor.
There's only one other wrinkle that's not obvious. The first MC doesn't have a way to check whether or not to fire off the gens.** But.
It turns out that if you have a gen instruction with a duration less than 0... the MC won't do anything for that part of the gen pulse. It's treated as though you said "gen p1 0 0" (which does nothing) instead of "gen p1 x1 0".
This way, when the MC receives a -999 from the radio, it runs a gen pulse for -999 (really 0) time units. No conditionals needed!
**(In case you're wondering, the flag used for the loop ( – ) - note that the loop must not run on a -999 - can't be used for the gen pulses, because the opposite flag ( + ) is set when the loop exits. But that same flag is set during the first test if the loop never runs, so whether I set those gen instructions to + or nothing wouldn't matter, as they'll always run.)
Interesting. I wonder if Mr. Haotian is investing in sustainability technology? Aquaponics systems can be set up in ways that they don't really require too much in the way of outside inputs, so this could be useful for, for example... feeding people in developing nations? Or in places where outside stuff can't easily get? Long-term rebuilding after disaster recovery, maybe?
We'll have to see.
P.S: I finally figured out something I can do with the prototyping area!
I'm not ready to say just what it is yet, but let's just say that my Secret Project is underway...